Automated software testing has many benefits for the software industry, and various tools are widely used. One of the major benefits of automated testing is that a test is written once and can be run many times. For example, when a change is made to the software, an automated test is the only efficient way to perform regression testing to assure that no new defects were added.
Another potential advantage is the ability to write a test for the initial language of the product, such as English, and then use the test for all the other languages of the product. For example, Eclipse is available in nine languages, so it would be helpful to have a single test that works on all languages.
Currently available techniques generally do nothing to facilitate multilingual testing. Most current methods require separate translations for user interface and data elements for each language tested. This allows switching languages, but the process of creating the data is essentially manual and requires special technical and linguistic expertise. There is no way to create the strings automatically, or to access strings used by the product under test.
Further, there exists the problem of dynamically discovering locale-related resources on an Eclipse platform that is under test by an automated test tool. These locale-related resources, typically textual strings, are used by a test tool (for example IBM Rational Functional Tester) in order to drive the application under test.
Typically to use an automated test tool, in particular a GUI (graphical user interface) test tool, on an Eclipse-based application, there are about 2 main approaches:
1. Extract all locale-related resources, such as textual strings in a base language (typically English) from a test script to one or several external Java “ResourceBundle” files. The number of these files is as many as the number of localized languages that an Eclipse-based application needs to support. These files are then translated, with the “base string” acting as the key and a corresponding value acting as the equivalent localized string in the target language.
It is noted that these external Java ResourceBundle files do not belong to the Eclipse-based application under test and are a duplication of a subset of ResourceBundles that are only relevant to and used by the automation tool.
2. Make available in the automated test tool's Java classpath the locations of all the ResourceBundle files that might be required by the tool, typically by specifying the jars files. These ResourceBundle files belong to the Eclipse-based application under test and need to be actively set up by the tester in the test tool.
The drawbacks of these two approaches are as follows.
Solution 1. above duplicates the creation of the ResourceBundle files of the Eclipse-based application under test and raises the issues of synchronizing the contents files with the ResourceBundles of an application under test in the long run. Over ten or more localized languages, this approach/solution becomes prohibitive in terms of time, manpower and costs.
Of the two solutions above, the second is preferred as it does not duplicate the creation of the ResourceBundle files of the Eclipse-based application under test. However, implicit in both solutions above is the requirement to know what the ResourceBundle files are and their locations. These files might be split or renamed from release to release. Insidious to the this approach is that ResourceBundles specific to the test tool(which is also Eclipse-based) might be accidentally picked instead of those from the application under test.
There is also an issue that the locale of the application under test might be different from the default locale of the OS system (operating system). Example, it is possible to run a localized Japanese Eclipse-based application on an English OS system.
Further Solution 2. needs to be able to have a means to dynamically discover the ResourceBundles it potentially needs according to the locale of the application under test.